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Abstract  -  The  Naval  Meteorology  and  Oceanography 
Command  (NAVMETOCCOM)  is  transforming  its  business 
model  and  processes  to  better  align  with  the  Naval  warfighter . 
Information  Technology  (IT)  is  an  enabler  for  this 
transformation.  This  paper  will  discuss  how  the  transformational 
IT  strategy  based  on  the  tenets  of  Net-Centric  Operations  and 
Warfare  (NCOW)  and  Service  Oriented  Architectures  (SOA)  are 
being  managed  and  applied  in  the  NAVMETOCCOM  Enterprise 
Architecture. 


I.  Navy  METOC  -  Who  we  are  &  what  we  do 

The  Naval  Meteorology  and  Oceanography  Command 
(NAVMETOCCOM)  is  a  third  echelon  Naval  command 
whose  mission  is  to  provide  environmental  information  to 
warfighters  and  their  mission  planning,  command  and 
control,  and  weapon  systems.  Environmental  information  is 
used  to  characterize  the  environmental  component  of  the 
battlespace  and  to  assess  impacts  to  warfighter  sensors, 
platforms,  weapons,  and  missions.  NAVMETOCCOM’s 
functional  domains  include  Meteorology  and  Oceanography 
(METOC),  Geospatial  Information  and  Services  (GI&S), 
and  Precise  Time  and  Astrometry  (PT&A). 

In  2004,  the  Commander  recognized  a  need  for  realignment 
in  order  to  enhance  responsiveness  to  its  warfare 
stakeholders.  In  September  2004,  COMNAVMETOCCOM 
conducted  a  seminal  meeting  that  set  the  stage  for  a 
transformation  from  geographically- oriented  support  to 
knowledge-based  support  aligned  to  the  Command's 
primary  business  lines,  specifically,  Warfare  Areas.  [1]  The 
meeting  formed  the  focus  of  transforming  the  Command 
tours  for  0-5/0-6  Naval  officers  from  the  Regional 
Centers/Production  Centers  to  Command  tours  as  Directors 
of  Oceanography  Operations  (DOO),  the  latter  conforming 
to  the  transformational  business  lines  for 
NAVMETOCCOM: 


•  Anti-Submarine  Warfare 

•  Navy  Special  Warfare 

•  Intelligence,  Surveillance,  and  Reconnaissance 

•  Mine  Warfare 

•  Precise  Time  and  Astrometry 

•  Navigation 

•  Fleet  Operations,  Strike,  and  Expeditionary  Warfare 

•  Maritime  Operations 

•  Aviation  Operations  [2] 

As  a  result  of  this  transformation,  the  Commander  has 
expressed  a  new  Mission:  "To  provide  an  asymmetric  war 
fighting  advantage  through  the  application  of 
Oceanographic  sciences."  [3] 

NAVMETOCCOM  supplies  a  Navy  strength...  the  ability 
to  apply  Oceanography  to  battle  problems  and  challenges  in 
order  to  leverage  knowledge  of  the  environment  to  enable 
asymmetric  advantage.  NAVMETOCCOM  provides  that 
advantage  for  the  Navy  through  the  application  of  its 
scientific  disciplines:  METOC,  GI&S  and  PT&A.  This 
advantage  is  delivered  through,  and  made  productive  at  the 
end  of,  an  information  and  services  supply  chain  managed 
solely  for  that  purpose.  This  information/services  supply 
chain  is  our  Naval  Oceanography  enterprise. 

The  opportunities  and  challenges  related  to  Enterprise 
Architecture  (EA)  to  enable  the  NAVMETOCCOM 
transformation  are  several,  and  will  be  explored  in  the 
remainder  of  this  paper.  At  a  paramount  level,  the 
NAVMETOCCOM  To-Be  EA  must  account  for  the 
business  functions  that  are  explicitly  and  implicitly  a  part  of 
each  business  line.  The  EA  must  both  account  for  the 
logical  and  physical  assets  that  are  associated  with  the 
former  Regional  Centers  and  describe  their  transition  to 
infrastructure  and  processes  needed  to  support  the  new 
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Concept  of  Operations,  regardless  of  the  spatial  distribution 
of  the  business  line  functions  (as  well  as  describe  the 
’’where"  of  the  business  lines). 

II.  DOD/DON  Transformation  Drivers  &  Constraints 

The  ability  of  the  Command  to  shape  its  Enterprise  is 
affected,  either  enabled  or  hindered,  by  forces  and 
constraints  outside  of  the  Command.  The  DoD  and  Navy 
are  migrating  to  Enterprise  Service  Oriented  Architectures; 
viz.  the  Global  Information  Grid  (GIG)  and  the  FORCEnet, 
respectively.  [4]  The  primary  impact  of  these  constructs  is  a 
requirement  for  the  NAVMETOCCOM  Enterprise  to 
similarly  present  itself  as  discoverable,  understandable,  and 
accessible  services  that  can  be  used  by  Warfighters,  either 
through  DoD  portals  or  as  discovered  by  other  DoD  systems 
via  a  machine-machine  interface.  One  negative  impact  -  the 
Department  of  Defense  Architecture  Framework  (DODAF) 
derives  from  an  older  paradigm  of  stove-piped  systems 
development;  it  has  been  argued  that  the  DODAF  is  not 
conducive  to  engineering  an  SOA.  [5]  As 
NAVMETOCCOM  migrates  to  an  SOA,  the  Systems  Views 
from  the  DODAF  would  properly  be  represented  as  Services 
Views.  [6]  Also,  the  services  that  are  to  be  provided  under 
the  GIG  Network  Centric  Enterprise  Core  Services  (NCES) 
are  not  yet  fully  available,  but  are  needed;  this  leaves  the 
Command  in  a  position  where  it  must  provide  them  directly 
in  advance.  The  Command’s  philosophy  is  to  migrate 
toward  a  knowledge  provider  that  utilizes  DoD  provided 
commodity  hardware  and  services.  [7] 

A  related  factor  is  the  existence  of  the  Navy-Marine  Corps 
Intranet  (NMCI),  a  seat  management  initiative  to  provide 
workstations  and  infrastructures  across  the  entire  CONUS 
Navy  and  Marine  Corps  enterprise.  The  provision  of  NMCI 
across  the  NAVMETOCCOM  enterprise  again  provides  an 
opportunity  to  make  use  of  commodity  hardware.  It  is  the 
Command’s  intent  to  use  NMCI,  when  available,  as  the 
target  platform  for  the  end  user’s  consumption  of  enterprise 
web  services.  However,  NMCI  does  not  yet  provide  a 
server  infrastructure  that  is  completely  suitable  for 
provisioning  the  services,  particularly  due  to  the 
requirement  to  reach  back  into  NAVMETOCCOM 
Production  Centers  for  extremely  large  data  stores  and 
leading  edge  supercomputing  processing  capacity  to  realize 
the  services.  Also,  many  of  the  applications  that  would  use 
METOC  web  services  are  components  of  Tactical  Decision 
Aid  and  Weapon  Decision  Aid  systems  that  are  not  a  part  of 
NMCI. 

A  complicating  factor  is  the  Navy’s  initiative  for 
"rationalization",  viz.  the  reduction  of  its  overall  numbers  of 
applications.  Navy  enterprise-wide,  the  target  was  95% 
reduction  of  100,000  applications.  [8]  This  process  was, 
and  is  being,  conducted  through  24  Functional  Areas,  each 
under  the  purview  of  a  Functional  Area  Manger  (FAM).  [9] 
The  FAM  for  Meteorology,  Oceanography,  GI&S  and  PTA 
is  COMNAVMETOCCOM.  The  Navy’s  rationalization 


approach  makes  sense  when  addressing  multiple  varieties  of 
spreadsheet  software,  for  example,  but  is  detrimental  when 
approaching  the  NAVMETOCCOM  software  baseline  on  a 
number-driven  basis.  METOC  has  a  large  number  of 
unique  applications  that  perform  very  specific  scientific 
calculations;  attempts  to  rationalize  them  are  problematic 
simply  because  of  the  unique  nature  of  the  Command’s 
business  model  (i.e.  deriving  METOC  information 
products.)  A  final  complicating  factor  with  regard  to  this 
rationalization  process  is  how  it  will  be  applied  in  a  SOA 
environment  where  application  boundaries  will  be 
significantly  blurred  across  multiple  enterprise  boundaries. 

In  summary,  the  net-centric  transformation  emerging  in  the 
broader  DoD  community  levies  a  requirement  for  process 
transformation  within  NAVMETOCCOM.  Further, 
aligning  to  the  SOA  of  the  GIG  requires  IT  transformation. 
These  transformations  have  to  be  accomplished  without 
additional  resources. 

III.  Implications,  Strategy,  &  Status  for  METOC 
Information  Technology 

As  described  above,  broader  DoD/DON  transformation 
efforts  have  levied  requirements  on  Navy  METOC 
programs  to  integrate  our  production  and  service  processes 
with  emerging,  net-centric  processes  of  the  warfighter. 
Furthermore,  since  we  must  make  this  transformation  in  the 
context  of  decreasing  budgets,  the  METOC  Enterprise  must 
employ  new  management  processes  and  supporting  tools  to 
enable  more  visibility  into  costs  and  effectiveness  of 
METOC  products  and  services.  Only  through  such 
visibility  will  management  be  able  to  make  critical  business 
case  decisions  for  investments  and  divestments.  The 
following  sections  define  the  establishment  of  a 
NAVMETOCCOM  Enterprise  Architecture  Framework 
(EAF)  to  support  better  management  practices  and  an 
approach  to  integrating  effectively  with  the  GIG  via  a 
METOC  SOA.  Fig.  1  depicts  a  very  high  level  IT 
architecture  that  reflects  the  presence  of  major  types  of 
METOC  nodes  and  services,  as  well  of  recognition  of  the 
central  role  of  the  GIG  in  facilitating  integrations  across 
multiple  IT  enterprises.  This  high  level  architecture 
provides  the  context  for  our  EA  efforts  and  transformation 
to  an  SOA  environment. 


Figure  1.  METOC  “To-Be”  Enterprise  Architecture  IT  Context 


A.  Enterprise  Architecture . . .  from  concept  to  daily  tool 

NAVMETOCCOM  has  a  history  of  development  and  use  of 
Enterprise  Architecture  beginning  around  2000,  although 
the  supporting  roots  go  back  to  the  1980s.  The 
NAVMETOCCOM  efforts  at  EA  have  been  conducted  at 
both  COMNAVMETOCCOM  and  at  its  production  centers. 
The  Naval  Oceanographic  Office  (NAVOCEANO)  started 
developing  its  architecture  in  2000,  using  the  DoD  C4ISR 
Architectural  Framework  (DODAF)  as  its  structure.  Over 
the  next  several  years,  NAVOCEANO  built  software  and 
database  structures  to  hold  the  information  descriptors  that 
would  comprise  its  architecture  artifacts.  Key  to  this  effort 
was  the  existence  of  a  robust  Configuration  Management 
(CM)  program  for  the  NAVOCEANO  enterprise.  (CM  was 
a  legacy  practice  at  NAVOCEANO  that  was  formalized  in 
the  1980s.)  The  NAVOCEANO  CM  databases  contained 
detailed  inventory  information  for  the  majority  of  the 
Office,  and  the  information  in  them  had  been  refreshed  for 
Y2K  planning.  As  a  result  the  first  efforts  to  establish  an 
EA  for  NAVOCEANO  began  with  the  DODAF  Systems 
Views.  By  2002,  NAVOCEANO  had  developed  its  initial 
EA  products;  specifically,  there  was  a  populated  database 
and  software  application  that  would  build  the  C4ISR  views 
on  the  fly. 

Concurrently,  NAVMETOCCOM  was  building  a  coupled 
EA.  In  2000,  the  Department  of  the  Navy  Chief 
Information  Officer  enlisted  the  Commander  to  participate 
in  a  demonstration  of  EA  at  an  operational  command.  For 


the  next  two  years,  DONCIO  staff  and  contractors  worked 
with  COMNAVMETOCCOM  staff  and  representatives 
from  the  Command  to  develop  a  C4ISR-compliant  EA.  In 
doing  so,  DONCIO  developed  a  tool  referred  to  as  the 
Department  of  Navy  Information  Architecture  Database 
(DIAD).  The  DIAD  was  the  tool  used  to  ingest  and  manage 
information  descriptors  relevant  to  the  Operational  Views  of 
the  C4ISR  AF.  By  the  end  of  2002,  a  NAVMETOCCOM 
EA  prototype  (Operational  Views  only)  had  been  populated 
and  the  results  were  briefed  at  a  DONCIO-sponsored  EA 
conference  in  Feb  2003.  [10]  During  this  period,  the 
Operational  Views  portions  of  the  NAVOCEANO  EA  were 
synchronized  with  the  DIAD  and  the  Systems  Views 
products  were  maintained  independently. 

From  2002  to  2004,  NAVOCEANO  had  been  modernizing 
its  architecture  tools,  migrating  from  a  single-user 
environment  deployed  on  Microsoft  Windows  platform 
using  COTS  packages,  to  a  web  based  open  source  (Linux) 
environment  using  open  source  tools.  [11]  Additionally,  the 
migration  tool  includes  capability  for  Configuration 
Management,  Requirements  Management,  and  CM  change 
tracking,  in  addition  to  the  original  EA.  That  is,  the  tool 
consolidated  a  number  of  legacy  IT  management  databases 
that  support  the  overall  architecture  objectives.  [12]  This 
tool  provided  the  foundation  for  the  current  EA  capability 
described  below. 


Current  Enterprise  Architecture  Framework 

The  purpose  of  the  NAVMETOCCOM  Enterprise 
Architecture  Framework  (EAF)  is  to  provide 
COMN AVMETOCCOM  and  all  of  its  subordinate 
commands  with  a  common  data  repository  to  manage  the  IT 
assets  and  architecture  for  the  Naval  METOC  community. 

The  EA  allows  NAVMETOCCOM  personnel  to  have  a 
common  entry  point  for  managing  IT  assets,  business 
processes,  network  topology,  requirements,  and  technology 
standards.  The  EAF’s  initial  capability  combined  the 
following  separate  functions: 

■  Identification  Management  (CIM)  In-House 
database  -  maintains  detailed  inventory  and 
configuration  information  about  the  systems 
that  comprise  the  enterprise. 

■  Configuration  Management  Office  (CMO) 
Tracking  System  Configuration  -  maintains 
approval  and  status  of  changes  to  the 
enterprise  baseline. 

■  DoD  Architecture  Framework  (DODAF) 
Repository  -  maintains  multiple  dimensions  of 
enterprise  views  that  meet  the  definitions  of 
the  Department  of  Defense  Architecture 
Framework. 

■  Requirements  Enterprise  Architecture 

Documentation  (READ)  -  maintains  a 
database  of  functional  and  system 
requirements  for  the  enterprise. 

The  DODAF  Repository  maintains  data  that  represent  the 
three  “views”  in  the  DODAF  specification:  Operational, 
Systems,  and  Technical.  Operational  Views  (OVs) 
represent  the  business  processes  of  the  enterprise,  including 
Processing  Nodes  (where  work  occurs),  Information 

Elements  (the  information  produced),  Information  Exchange 
Requirements,  and  Processes.  The  Systems  Views  represent 
the  physical  components  (hardware,  software,  networks) 
that  provide  the  computing  capability  that  is  used  by  the 
elements  described  in  the  OVs.  The  Technical  Views 
describe  the  technical  specifications  and  standards  used  in 
the  items  described  in  the  SVs. 

B.  IT  Transformation...  assimilating  Net-Centric  &  SO  A 
Tenets 

As  described  above,  a  fundamental  transformation  is 
underway  in  the  DoD.  This  transformation  is  characterized 
by  process  transformations  that  embrace  the  tenets  of  Net- 
Centric  Operations  and  Warfare  (NCOW)  and  IT 
transformations  that  require  DoD  systems  to  integrate  with 
the  GIG  and  to  embrace  the  tenets  of  an  SOA. 
Understanding  SOA  and  its  relevance  to  the  Naval 


Oceanography  Program  is  key  to  defining  an  effective 
transition  strategy  for  our  community. 

Primarily,  SOA  is  a  software  design  model  that  guides 
software  engineers  to  package  capability  into  units  of  work 
that  can  be  discovered,  understood,  accessed,  and  used  by 
developers  and  systems  anywhere  on  the  GIG.  It  is  also 
defined  by  emerging  technology  standards  that  enable  its 
implementation,  as  well  as  design  principles  and 
management  best  practices  that  must  be  applied  to  assure  it 
will  deliver  expected  benefits  to  the  warfighter. 

Properly  implemented,  SOA  will  provide  benefits  to  the 
warfighter.  An  effective  SOA  provides  a  common 
integration  mechanism  that  can  span  multiple  systems, 
technologies,  and  organizations  located  anywhere  on  the 
network;  warfighters  (and  their  systems)  are  benefited  by 
having  comprehensive  but  selective  access  to  discoverable 
data,  information,  and  knowledge  most  relevant  to  their 
decisions  and  operations.  Further,  it  will  improve  Return  on 
Investment  (ROI)  on  all  IT  investments,  including  already 
deployed  legacy  applications  and  systems. 

SOA  is  not  only  mandated  by  the  GIG  Architecture  (as 
articulated  in  the  NCOW  Reference  Model  [13]),  it  is  also 
embraced  by  every  major  IT  vendor  in  the  form  of  XML 
and  web  services  solutions. 


Navy  METOC  SOA  Strategy 

To  become  a  net-centric  player  in  the  emerging  DoD  SOA 
environment,  new  IT  technologies  must  be  employed. 
Reusable  software  entities,  called  services,  must  be 
deployed  and  offer  specific  benefits  to  the  operators  and 
their  systems.  Further,  new  infrastructure  technology  must 
be  available  to  host  these  services  and  support  their 
interoperability,  composition,  and  management.  An  optimal 
mix  of  projects  must  be  identified,  selected,  and  effectively 
executed  to  accomplish  these  integrations.  New  technical 
skills  in  the  area  of  software  design,  and  new  management 
approaches  to  software  development  and  reuse  must  be 
applied  in  these  processes.  These  new  skills  and  practices 
are  not  currently  employed  in  the  formulation  or  execution 
of  most  DoD  IT  projects,  adversely  affecting  their  readiness 
to  deploy  effective  SOA  solutions. 

The  Naval  Oceanography  Program  must  define  and 
implement  a  strategy  that  accomplishes  the  following  goals: 

•  transition  the  end-to-end  enterprise  to  SOA 
compliance 

•  maximize  IT  investments  that  produce  “visible” 
warfighter  value  on  a  continuing  basis 

•  minimize  required  IT  costs  for  non-core  functions 
(e.g.  internal  infrastructure  hardware  and  software) 


•  develop  and  apply  the  new  technical  skills  and 
management  best  practices  required  for  assuring 
SOA  success 

•  ensure  alignment  of  IT  projects  to  architecture 

The  implementation  of  this  strategy  is  embodied  in  the 
portfolio  of  projects  that  we  select  to  meet  these  goals  and  in 
the  mechanisms  we  create  to  achieve  a  tipping  point  of 
common  understanding  and  alignment  across  our  major  IT 
efforts. 

The  remainder  of  this  section  proposes  an  ideal  IT  Portfolio 
for  SOA  integration  into  the  Naval  Oceanography  Program, 
based  upon  the  goals  defined  above.  In  subsequent  sections, 
the  status  of  current  and  planned  METOC  technical  and 
managerial  efforts  with  regard  to  SOA  is  presented. 

An  objective  method  is  required  to  characterize  the  nature  of 
an  IT  project  that  is  focused  around  integration  issues,  since 
integration  is  the  primary  driver  for  SOA  adoption.  This 
method  will  be  used  to  define  an  ideal  IT  Portfolio 
Management  for  SOA  Integration.  Fig.  2  depicts  a  matrix 
of  factors  that  impact  the  complexity,  cost,  and  risk  (CCR) 
of  an  IT  integration  project.  Projects  can  be  placed  in  this 
matrix  to  give  a  qualitative  assessment  of  their  CCR  profile. 
The  vertical  axis  indicates  the  scope  of  the  integration  from 
a  single  application  at  a  single  node  to  enterprise-wide 
integration  between  nodes  of  different  organizations.  The 
horizontal  axis  indicates  the  type  of  integration  from  just 
integrating  pictures  to  integrating  diverse  processes.  The 
diagonal  axis  indicates  the  specificity  of  the  requirement(s) 
driving  the  integration  from  known  single  requirements  to 
infrastructure  upgrades  required  to  support  many,  perhaps 
unknown  requirements. 

How  should  the  ideal  portfolio  of  SOA  Integration  Projects 
map  onto  this  matrix  given  the  goals  of  our  transition 
defined  above?  One  answer  is  to  minimize  IT  investment 
risk  by  focusing  first  on  projects  with  lower  cost  and 
complexity;  but  with  significantly  visible  benefits  for  the 
warfighter.  Then,  as  SOA  knowledge  and  skills  mature 
within  the  Naval  Oceanography  Program,  and  as  DoD/DON 


infrastructure  capability  increases,  the  more  challenging 
issues  of  broad  scale  SOA  integrations  could  be  attacked. 

Fig.  3  depicts  a  portfolio  model  that  defines  four  tiers  of 
projects,  each  with  an  increasing  CCR  profile.  The  ideal 
approach  would  move  from  Tier  1-2  projects  to  Tier  3-4  as 
technical  and  management  competence  with  regard  to  SOA 
develops,  thereby  reducing  risk  and  focusing  results  on 
visible  benefits  for  the  warfighter.  Selecting  projects  in  Tier 
1-2  first  has  the  added  benefit  of  focusing  our  early  SOA 
integration  projects  where  we  have  interested  and  ready 
warfighter  partners  with  regard  to  consuming  METOC  web 
services,  defined  in  terms  they  understand. 

Navy  METOC  Technical  SOA  Projects  Status 

There  are  three  major  projects  underway  that  are 
contributing  to  the  evolution  to  an  SOA  environment. 
These  include  Fleet  Numerical  Meteorology  & 
Oceanography  Center’s  (FNMOC’s)  ATOS2  Project, 
SPAWAR’s  VNE-NCS,  and  CNMOC’s  Web  Services/Web 
Portal  Project.  Mapping  the  scope  and  approach  of  each  of 
these  projects  onto  this  matrix  highlights  these  conclusions: 
the  current  portfolio  holds  more  risk  than  the  ideal  model  as 
they  tackle  more  scope  and  complexity  without  significant 
experience  in  fielding  operational  web  services;  there  is 
some  overlap  in  capability,  both  between  Naval 
Oceanography  Program  projects  and  with  the  DoD  Net- 
Centric  Enterprise  Services  (NCES)  program  [14];  there  are 
important  gaps  that  should  be  considered  in  near-term 
investment  decisions.  This  mapping  is  depicted  in  Fig.  4. 

To  provide  more  balance  in  the  Naval  Oceanography 
Program  portfolio  and  to  reduce  future  risk  in  SOA 
implementations,  projects  that  focus  on  single  and  specific 
integration  requirements  with  clearly  identified  warfighter 
systems  should  be  pursued.  Further,  we  should  expand  the 
types  of  integration  to  include  presentation  and  logic 
integration,  as  well  as  data  services  beyond  the  Joint 
METOC  Broker  Eanguage  (JMBE)  data  service. 
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Figure  2  -  Qualitative  Assessment  Matrix  for  Cost,  Complexity,  and  Risk  for  Integration  Projects 
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Figure  3  -  Picking  the  right  projects  -  Ideal  CCR  Profile  -  Incremental  Investment 
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Figure  4  -  METOC  SO  A  Portfolio  Gaps 


Navy  METOC  Managerial  SOA  Efforts  Status 

There  is  a  need  to  elevate  the  Naval  Oceanography 
Program’s  Technical  and  Management  Readiness  to 
Implement  SOA.  Improved  readiness  will  be  achieved  by 
establishing  mechanisms  to  create  and  maintain  common 
understanding  of  SOA  integration  issues,  to  align  Naval 
Oceanography  Program  IT  efforts  to  address  these  issues 
and  to  maximize  interoperability,  and  to  minimize  required 
IT  costs  for  functions  not  core  to  METOC  value  (internal 
infrastructure  hardware  and  software). 

The  implemented  mechanisms  must  effectively  link  both 
top-down,  enterprise-wide  efforts  with  bottom-up 
implementation  activities.  Specific  linkages  to  be  addressed 
include  the  following: 

•  link  enterprise-wide  policy/standards  development  & 
enforcement  with  the  technical  and  management 
implications  of  SOA  adoption 

•  link  planned  architectures  to  higher  level  guidance 
and  to  the  Concept  of  Operations  and  business 
priorities  of  METOC  Directorates 

•  link  planned  architectures  to  the  implementation 
efforts  of  Naval  Oceanography  Program  PORs;  both 
in  terms  of  architectural  compliance  and  in  terms  of 
applying  lessons  learned  to  evolving  architectural 
components 

•  link  infrastructure  investments  of  required,  non-core 
IT  across  METOC  nodes  to  optimize  cost  reduction 
and  leveraging  of  technology  expertise. 


The  most  efficient  way  to  maintain  these  linkages  is  in  the 
form  of  a  body  of  people  that  share  a  common 
understanding  and  vision  of  SOA  and  its  implications. 
These  people  must  be  key  players  in  influencing 
policy/standards,  understanding  how  to  translate  business 
requirements  into  automation  requirements  and  designs,  and 
in  the  ultimate  implementations  of  the  designs.  These 
people  must  be  drawn  from  all  major  Naval  Oceanography 
Program  IT  elements.  Assuring  architectural  and  cross¬ 
program  alignment  requires  an  empowered  mechanism  to 
promulgate  common  SOA  knowledge  and  ensure 
compliance  in  implementations. 

The  Navy  METOC  Enterprise  has  created  the  METOC 
Architecture  Team  (MAT)  to  build  a  new  core  architecture 
capability  within  the  enterprise.  The  goals  of  the  MAT  are: 

•  to  build  a  core  team  of  SOA  technical  architecture 
expertise 

•  to  bring  technical  understanding  and  alignment 
across  all  acquisition  and  implementation  programs 

•  to  provide  continual  focus  on  “To-Be”  architectures 
and  transition  strategies  from  “As-Is”  architectures. 

The  role  and  relationships  of  this  team  to  other  enterprise 
entities  are  depicted  in  Fig.  5.  These  cross-cutting 
relationships  are  typical  for  architecture  as  it  sits  at  the 
intersection  of  policy,  technology,  culture,  requirements, 
etc. 
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Figure  5  -  METOC  Architecture  Team  Roles  &  Relationships 


The  participating  entities  are  defined  as: 

•  Chief  of  Oceanography  Operations  (COO),  Directors 
of  Oceanographic  Operations  (DOOs),  and 
Production  Center  Technical  Directors  (TDs)  - 
Provides  driving  concepts  of  operations, 
requirements  for  architecture  development. 

•  CNMOC  N6  (CIO  of  the  Navy  METOC  Enterprise) 
-  Provides  authoritative  constraints,  guidelines,  and 
policy  context  for  architectural  development. 

•  Programs  of  Record  (PORs)  and  Production  Centers 
(PCs)  -  Provide  the  acquisition,  systems  engineering, 
and  implementation  support  to  realize  specified 
architectures. 

•  External  Liaisons  -  Links  to  critical  partners  and 
R&D  efforts  to  assure  architectural  alignment  to 
planned  operational  architectures. 

The  MAT  will  have  core  members  including;  Lead  IT 
Architect/MAT  Lead;  Chief  Engineers  from  implementation 
programs;  a  COO  designate;  and  IT  Governance  Lead. 
Other  CNMOC  N6  Directors  and  DOO  participants  will  be 
brought  in  as  issues  dictate.  This  team  is  required  to  sign 
off  on  implementation  plans  of  all  major  METOC  IT 
Projects  with  regard  to  architecture,  interoperability,  and 
integration  approaches. 

Early  MAT  efforts  will  be  driven  by  the  SOA  transition 
strategy  defined  above.  There  will  be  a  combination  of  top- 
down  and  bottom-up  architecture  development  efforts.  The 
results  of  all  these  efforts  will  be  used  to  populate  “To-Be”, 


just-in-time  “As-Is”,  and  transition  plans  in  the  Navy 
METOC  EAF.  The  top-down  efforts  will  develop  DODAF 
Operational  Views  (net-centric  CONOPS  and  process 
definitions)  for  each  warfare  area.  The  bottom-up  efforts 
will  evaluate  high  value  applications  for  functionality  that  is 
appropriate  for  early  SOA  deployments. 

The  results  of  these  analyses  will  contribute  to  the  initial 
definition  of  the  METOC  Enterprise  Service  Integration 
Layer  (MESIL),  the  key  SOA  specification.  In  addition,  the 
MAT  will  begin  evaluation  of  the  need  for  a  METOC 
Service  Integration  Bus  (ME SB)  and  how  METOC  net- 
centric  nodes  will  ingrate  with  the  ME  SB  and  the  DoD 
ESB,  called  Net-Centric  Enterprise  Core  Services  (NCES). 
This  architecture  development  process  is  depicted  in  Fig.  6. 

Finally,  it  is  critically  important  that  funded  IT  projects 
move  towards  realization  of  an  enterprise  SOA.  Each 
project  must  consider  the  same  critical  factors  to  assure 
alignment.  These  factors  fall  under  the  following  four  areas 
of  concern: 

•  Build  Net-Centric  System  Nodes 

•  Transition  Data  and  Application  Capabilities  to 
Services 

•  Apply  Technical  and  Management  Best  Practices 

•  Implement  Reuse  Project  Management  Practices 

Fig.  7  depicts  the  critical  considerations  for  each  area.  The 
MAT  has  created  checklist  questionnaires  aligned  with  each 
of  these  areas  to  assist  Program  Managers  and  Technical 


Project  Managers  in  considering  and  assessing  their  level  of 
alignment  to  Net-Centric  and  SOA  concerns.  These 
documents  were  created  based  upon  authoritative  guidance 
and  review  of  industry  best  practices  with  regard  to  SOA 
development.  Ref.  [13]  is  a  primary  driver  as  well  as  the 


actionable  guidance  from  Net-Centric  Enterprise  Solutions 
for  Interoperability  (NESI)  document  set  [15],  and  best 
practice  review  from,  “SOA  Concepts,  Technology,  and 
Design”  by  Thomas  Erl  [16]. 
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Figure  6  -  MAT  Analysis  Approach 
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Figure  7  -  Common  Critical  SOA  Integration  Project  Elements 


C.  Navy  METOC  EA  &  SOA  Summary 
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